Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build 0.19b2 #53

Closed
wants to merge 55 commits into from
Closed

build 0.19b2 #53

wants to merge 55 commits into from

Conversation

amueller
Copy link
Contributor

jakirkham and others added 30 commits September 27, 2016 16:40
* 0.18 version bump

* use git tag instead of pipy

* fix hash, move to sha256
* 0.18 version bump

* use git tag instead of pipy

* fix hash, move to sha256
…render_master

MNT: Re-render the feedstock [ci skip]
…render_master_np1.10

MNT: Re-render the feedstock [ci skip]
….10_1.4.6

MNT: Re-rendered with conda-smithy 1.4.6 [ci skip]
MNT: Re-rendered with conda-smithy 1.4.6 [ci skip]
…rsion_pin_master

MNT: Update pinned versions.
…rsion_pin_master_np1.10

MNT: Update pinned versions.
…1.10__1.7.0

MNT: Re-rendered with conda-smithy 1.7.0 [ci skip]
….7.0

MNT: Re-rendered with conda-smithy 1.7.0 [ci skip]
numpy 1.12 and python 3.6 support
MNT: Re-rendered with conda-smithy 2.0.1
@amueller
Copy link
Contributor Author

this is copied from master basically. It looks like it's only building one numpy version. Is that the standard?

circle.yml Outdated
@@ -1,6 +1,6 @@
checkout:
post:
- ./ci_support/checkout_merge_commit.sh
- ./ci_support/fast_finish_ci_pr_build.sh
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Weird that we are losing checkout_merge_commit.sh. Could you please try re-rendering again?

@jakirkham
Copy link
Member

Not going to have lots of time to look at this near term as I'm buried with other work.

It looks like it's only building one numpy version. Is that the standard?

If you recall, we had to create separate branches for each NumPy version because of the time limits with CircleCI. ( #52 ) So we will likely need to do the same thing with the rc branch.

@amueller
Copy link
Contributor Author

oh, right...

@amueller
Copy link
Contributor Author

rerendered

@jakirkham
Copy link
Member

Looks better. Thanks.

Yeah, we should have a better solution for the NumPy matrix once PR ( conda-forge/conda-smithy#532 ) is merged. Though there has been some discussion about doing NumPy pinning totally differently, which could also help if it works well. ( conda-forge/pandas-feedstock#32 ) Could try the different pinning in this release as well if you would like.

@jakirkham
Copy link
Member

Actually ignore the pandas suggestion as it doesn't work here due to blas support. We would need to go to multiple branches.

@amueller
Copy link
Contributor Author

So merge this and then do multiple branches for the different numpy releases?

@jakirkham
Copy link
Member

We can do that. While this is a bit unorthodox, I'm kind of want to re-rendering with the development version of conda-smithy to get CircleCI matrix support to see how that goes. Thoughts?

@amueller
Copy link
Contributor Author

yeah sure, go for it.

Re-renders with a dev version of `conda-smithy`, which provides support
for build matrices in CircleCI. While this feature has had some testing,
it has not gone live yet and should not generally be used until it is
released.
Re-renders with a dev version of `conda-smithy`, which provides support
for build matrices in CircleCI. While this feature has had some testing,
it has not gone live yet and should not generally be used until it is
released.

Adds in the other NumPy versions to CircleCI and Travis CI matrices.
@jakirkham
Copy link
Member

Done. Unfortunately CircleCI puts each build in a separate status. That said, it is tolerable given we actually get a build matrix. :)

@jakirkham
Copy link
Member

There seems to be a compilation error. Thoughts?

Error compiling Cython file:
------------------------------------------------------------
...

    cdef inline DTYPE_t dist(self, DTYPE_t* x1, DTYPE_t* x2,
                             ITYPE_t size) except -1 with gil:
        cdef np.ndarray x1arr
        cdef np.ndarray x2arr
        with gil:
            ^
------------------------------------------------------------

@ogrisel
Copy link
Contributor

ogrisel commented Jul 24, 2017

Indeed a change in cython 0.26 makes this construct invalid. This has been fixed in master and needs to be backported to the 0.19.X branch. Would it be possible to build 0.19b2 with Cython 0.25.2 in the mean time? It's just a build dependency, scikit-learn does not need cython at runtime.

@jakirkham
Copy link
Member

Sorry fixed in which master? scikit-learn or cython?

In either case, pinning cython to an older version is perfectly acceptable.

@amueller
Copy link
Contributor Author

Fixed in scikit-learn master.

amueller and others added 3 commits July 24, 2017 11:04
Re-render with a development copy of conda-smithy to add matrix support.
@jakirkham
Copy link
Member

Thanks for the info. Have re-rendered with development version of conda-smithy again to get the matrix back. I don't think there will be any need for further re-renderings, but we can discuss if needed.

@amueller
Copy link
Contributor Author

amueller commented Jul 24, 2017 via email

@ogrisel
Copy link
Contributor

ogrisel commented Jul 25, 2017

LGTM.

I backported the GIL fix in the scikit-learn 0.19.X branch so that 0.19 final won't have this problem anymore.

This was referenced Jul 31, 2017
@lesteve lesteve closed this Sep 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants